Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9608/000027_owner-urn-ietf _Fri Aug 23 19:12:29 1996.msg

Internet Message Format | 1997-02-19 | 3KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id TAA24131 for urn-ietf-out; Fri, 23 Aug 1996 19:12:29 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id TAA24126 for <[e-mail]>; Fri, 23 Aug 1996 19:12:23 -0400
Received: from lysithea.lcs.mit.edu by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA15803  (mail destined for [e-mail]); Fri, 23 Aug 96 19:12:21 -0400
Received: (from sollins@localhost) by lysithea.lcs.mit.edu (8.6.9/8.6.9) id TAA10444; Fri, 23 Aug 1996 19:12:20 -0400
Date: Fri, 23 Aug 1996 19:12:20 -0400
Message-Id: <[e-mail]>
From: "Karen R. Sollins" <[e-mail]>
To: [e-mail]
Subject: [URN] concerns
Sender: [e-mail]
Precedence: bulk
Reply-To: "Karen R. Sollins" <[e-mail]>
Errors-To: [e-mail]

I have a couple of concerns here having to do with scope of the
problem and manageability of the solution.  It seems that in
discussion, whether or not in the text of the documents, the authors
of the NAPTR framework and proposal papers want to provide resolution
for all possible namespace schemes.  Perhaps we would all be better
off and have a higher probability of success, if we identified a
smaller set of namespaces to which we were addressing our attention.
By limiting the set of namespace schemes we might find that two
additional concerns might be easier to address.

1) With foreknowledge of some syntactic constraints on URN schemes, we
could reduce the probability of chaos from the otherwise uncontrolled
regular expressions needed to parse and transform aspects of schemes.
Although only a very small number of people have been commenting on
the mailing list, I heard a great deal of concern about this in
Montreal.

2) With less complexity in the overall namespace structuring,
migrating to a future set of mechanisms that do not involve regular
expressions and the DNS might be manageable.  Again, there was
significant concern expressed about this in Montreal, although not on
the mailing list since then.  This is a problem that is not addressed
in the NAPTR related papers, but should be central to any plan that is
proposed.

I realize that these statements are not concrete.  That is
intentional, in order that we begin to set out the scope of what we
want to do as an alternative to discussing mechanism with some assumed
but perhaps not well stated scope in mind.

            Karen Sollins

___________________________________________________________________
Karen R. Sollins                [e-mail]
Research Scientist                Phone: [phone]
M.I.T. Laboratory for Computer Science        Fax:   [phone]
545 Technology Square
Cambridge, MA 02139